Stateless communication protocols such as HTTP (Hypertext Transfer Protocol), XML, or SOAP execute each command independently, without maintaining any state information of previous commands. As such, in a strictly stateless protocol, a server will not store the identity of a client device that previously communicated with the server, and thus will not process a current transaction of the client in light of previous transactions.
Server state objects such as cookies or hidden fields are thus commonly used to identify a client device communicating with a server using a stateless communication protocol. For example, a cookie is a server state object that allows the server web site to store its own information about the client device on the client device so that the server web site can later determine the identity of the client device. Thus, a server can determine that a client device is has previous communicated with the server by examining the server state objects, and allow the client device to transact with the server based upon the established identity without additional efforts to identify the client device.
Since server state objects identify a client device to a server and allows the client device to communicate with the server based upon the determined identity, the server should have a way to protect itself from fraudulent attempts to assume a certain identity of the client device. Thus, server state objects are typically immutable under stateless communication protocols in order to prevent the server from such fraudulent attempts. That is, when the server sends a server state object to the client device, the server expects the same server state object to come back without being changed or tampered on the client device.
Under a structured, well-defined communication protocol such as HTTP, an intermediate server, such as a firewall, gateway, or application proxy, may easily identify a server state object among the packets transmitted between an application server and the client device, because the packets containing the server state objects are configured to include certain fields that identify such server state objects. For example, a cookie includes a string such as <set-cookie: . . . > and a hidden field includes a string such as <input type=hidden . . . >, which can be readily identified by the intermediate server.
However, in less structured stateless communication protocols such as XML or SOAP, an intermediate server cannot readily identify server state objects, because these protocols are designed to allow application designers to define their own objects arbitrarily. Intermediate servers, such as firewalls, typically do not have access to the protocol definition given in the application server by the application designers, and thus server state objects arbitrarily defined by the application designers cannot be readily identified by the intermediate server. For example, in one application server, a server state could be held in an “ACCOUNT NUMBER” object while in another application the same server state could be held in a “CLIENT ID” object. The application server would have access to these protocol definitions and thus can identify these server state objects. However, the intermediate server (firewall or other filter) will not have the protocol/application definition of all applications behind the intermediate server.
Therefore, there is a need for identifying, by an intermediate server, server state objects transmitted between a server and a client device under a less structured stateless communication protocol such as XML or SOAP that does not have a predefined way of identifying the server state objects.